count_distinct currently returns an array (from $addToSet) and is never converted to a numeric count in the pipeline, so query results will be incorrect. A concrete fix is to detect count_distinct measures and, in the $project stage, project { $size: '$<measureName>' } (or add an additional projection stage) so the final output is a number.

Several operators are mapped to Mongo operators that won’t work with the way $match is built here: contains is mapped to $regex but passed a raw string (often needs a RegExp or a { $regex, $options } pattern), notContains maps to $not but $not expects an operator expression (commonly { $not: { $regex: ... } }), and inDateRange maps to $gte but should apply both $gte and $lte on the same field. Consider handling these operators explicitly when building matchStage instead of relying on convertOperatorToMongo alone.

Using truthy checks here causes offset: 0 and limit: 0 to be ignored (even if the caller explicitly sets them). Use an explicit query.offset !== undefined / query.limit !== undefined (or != null) check so zero values are respected.

If there are multiple filters targeting the same fieldPath, this logic overwrites the previous condition (last filter wins), which will produce incorrect filtering. A concrete approach is to build an $and array of per-filter expressions (or merge operators onto the same field where safe) and emit $match: { $and: [...] } when needed.

If there are multiple filters targeting the same fieldPath, this logic overwrites the previous condition (last filter wins), which will produce incorrect filtering. A concrete approach is to build an $and array of per-filter expressions (or merge operators onto the same field where safe) and emit $match: { $and: [...] } when needed.

timeDimensions includes granularity, but this implementation only applies a date range filter and does not transform/group by time buckets. If callers expect results grouped by day/week/month via timeDimensions.granularity, the current output will be wrong. Consider incorporating time dimensions into the $group._id (and projected fields) by adding a computed bucket expression (e.g., date truncation / formatted date key) when granularity is provided.

AnalyticsQuery (TypeScript contract) now includes order?: Record<string, 'asc' | 'desc'>, but AnalyticsQuerySchema does not define order. This can cause runtime validation to reject otherwise-valid requests (or strip the field, depending on schema settings). Add order to the Zod schema to keep runtime validation aligned with the contract.

AnalyticsQuery (TypeScript contract) now includes order?: Record<string, 'asc' | 'desc'>, but AnalyticsQuerySchema does not define order. This can cause runtime validation to reject otherwise-valid requests (or strip the field, depending on schema settings). Add order to the Zod schema to keep runtime validation aligned with the contract.

This change removes the top-level cube field from the request body schema (previously cube was a sibling of query). If this endpoint is already consumed externally, this is a breaking request-shape change. Consider supporting both shapes during a deprecation window (e.g., accept cube at the top level and/or inside query, then normalize), or ensure versioning/migration guidance is in place.

This test asserts a deterministic ordering for tied sort keys (Alice and Bob both have totalAmount 250). Since tie-breaking order isn’t guaranteed unless explicitly specified, this can be flaky across implementations/versions. Make the expectation order-insensitive for ties, or add a secondary sort in order (e.g., also sort by orders.customer).